The X and Motif systems are complex libraries aimed at C programmers. This section will explain the benefits developers can expect from GUI builders and will present a classification of GUI builders.
The X/Motif model of an
application
The X Window System and Motif are implemented as function libraries intended to be called from a C application. These libraries implement fairly low level functions for the creation and manipulation of the objects that constitute the interface. The libraries do not further a particular design method and result in a lengthy development cycle. The structure of an application as modelled in the X window system is the following:
The application is divided into two parts: the GUI and the application proper.
The GUI part of an application contains the code to create the graphic components - buttons, labels, scrollbars, windows and so on - that are part of the GUI. The application proper consists of the code that is called back when an interface event occurs.
An important notion of X is that of event. X events are significant events that occur on the interface, essentially, mouse clicks and keyboard strokes. An X application is event driven - it consists of a main loop that awaits an event and then triggers an action in the application.
Every Motif widget has its given and unchanging set of events. For example, a Motif button has an "activate" event that is triggered when the user clicks with the mouse within the button. There are many kinds of events and we refer the reader to a description of the X Window System and of Motif for more details.
To design the application with the X Window System and Motif, you must program the GUI entirely. If you want to place a button you call the button creation function to which you give as parameters the position, size and other graphic attributes (called resources in X) of the button. If you later want to change the GUI, you must change the program, recompile and debug - i.e. you enter the costly edit - compile - debug software development cycle.
In X, the communication between application and GUI is only through callbacks. X does not provide any other mechanism for transferring data. This shortcoming has been corrected in through the active values mechanism.
The Seeheim model of an application and its GUI
A widely used decomposition of an application and its GUI in structural components is the so- called Seeheim model (named after the location of the technical conference where it was first formally defined). The Seeheim model is illustrated in the following figure:
The main difference between these two models is that in the Seeheim model, the GUI is split into the layout and the dialog part. This distinction is useful in guiding developers in the design of applications.
The layout component consists of the graphic objects of the GUI and their geometric attributes. The behavior component is in charge of all the actions that have an effect on the interface itself. Two kinds of actions can be triggered by a GUI event:
Interface actions - actions that have an
effect on the
GUI itself. As a
simple example, hiding a box when pressing the OK button. Often, such actions
can
be much more complex.
Application actions - actions that are not related
to
the interface but are
specific to the application. In the same example, pressing the OK button
may also
launch a computation in
the application, whose results will eventually have to be displayed in the
GUI.
Interface actions define the dialog between user and the application. We call this GUI behavior or GUI dialog.
GUI behavior is independent of the application proper. The application proper should not be concerned with the way the GUI dialog is implemented. Allowing the GUI building tool to handle both GUI layout and GUI behavior frees the application proper from all GUI concerns. Ultimately, this allows a change of the GUI without affecting the application proper. We shall see later how XFaceMaker puts this cardinal principle into practice.
Classification of GUI builders
There are two types of GUI builders:
Interface Development Tools (IDTs) -
tools for the design of the layout
component only.
User Interface Management Systems (UIMS) -
tools for the design of both the
layout and
the behavior component.
Interface development tools (IDTs)
With such a tool you only lay out the interface and generate C code for the GUI part. The developer must then provide the application proper which he inserts into stubs, i.e. slots that are provided for it in the code generated for the GUI. IDTs follow closely the application model provided by X and Motif. They only go halfway through in solving the GUI design problem.
Since a big portion of a GUI is graphical, an interactive CAD tool is much better for designing the GUI layout than a program library such as the Xlib and Motif. Although IDT's solve a major part of the GUI design problem, they leave out a major portion.
User interface management systems (UIMS)
UIMS allow the design of both GUI layout and GUI behavior. GUI behavior is usually specified by means of dialog scripts, or simply scripts. Scripts are often expressed in a high-level programming language. In XFaceMaker, this language is a C-like language called FACE. Other products may use C itself or other types of languages.
Some UIMS products contain an interpreter and/or a debugger allowing the immediate test of dialog scripts without leaving the tool. But most importantly, and this is their superiority over IDT's, they clearly separate both GUI layout and GUI behavior from the application proper. As a result, it is much simpler to modify an interface designed with a UIMS than one designed with an IDT, in which GUI behavior code is inextricably mixed with the application code.
Single-toolkit versus
multistandard GUI builders
Single toolkit GUI builders use a toolkit in the native form in which it is made available by the computer manufacturer. XFaceMaker, for example, uses the X/Motif toolkit. The advantage is that they allow the full use of all the capabilities of a toolkit and faithfully conform to the corresponding standard.
Multi-toolkit GUI builders intend to let you design GUIs for several graphic standards at once rather than redevelop it from scratch for each new toolkit. The main approach for multi-toolkit GUI builders is to implement a subset of widgets, common to the several graphic standards. This is often called the "least common denominator" approach. It has the drawback of leaving aside the best feature of each standard.
